Aggregate Constraints for Payment Transactions

ABSTRACT

This document describes tools capable of authorizing or enabling authorization of multiple payment transactions without requiring that a buyer or seller authorize each transaction separately. The tools may do so by enabling a buyer or seller to select aggregate constraints, such as a total price or number of transactions. Based on these selected constraints, the tools may authorize every payment transaction that meets the aggregate constraints without requiring the buyer to authorize every transaction separately.

RELATED APPLICATIONS

This application is a divisional of U.S. patent application Ser. No.11/694,459, filed on Mar. 30, 2007, which claims the benefit of U.S.Provisional Application No. 60/882,855, filed on Dec. 29, 2006. Theentire contents of both of these applications are incorporated herein byreference.

BACKGROUND

Sellers offer and buyers purchase countless products and services overthe Internet. To do so, buyers and sellers typically authorize a paymenttransaction for each purchase.

Assume, for example, that a buyer named “Bonnie” purchases three itemsfrom a seller named “Sam”. Bonnie purchases a book from Sam on Monday, aDVD on Wednesday, and downloads a song on Friday. To pay for theseitems, Bonnie first sets up an account on Sam's website, enters hername, credit-card number, and address. On Monday she selects the book,is directed to a purchase screen where she checks on the price and otherdetails, and then selects to purchase the book. On Wednesday she selectsthe DVD and, even if her account information is saved and readilyavailable, she still has to check through the price and other detailsbefore she can select to purchase the DVD. On Friday she selects thesong, checks that the price and other details are correct, and thenselects to purchase the music. Bonnie separately authorized threedifferent payment transactions.

Assume, also for example, that a buyer name “Billy” wants to purchasethe right to play video games online from many different sellers ofonline gaming services. Each time he wants to play a game he may need toauthorize a payment transaction. If he plays two games on Monday, one onTuesday, and twelve games on Saturday, he may need to separatelyauthorize fifteen payment authorizations. As this and the other exampleillustrates, requiring a buyer to separately authorize paymenttransactions for multiple items or services can be tedious and timeconsuming.

SUMMARY

This document describes tools capable of authorizing or enablingauthorization of multiple payment transactions without requiring that abuyer or seller authorize each transaction separately. The tools may doso by enabling a buyer or seller to select aggregate constraints, suchas a total price and number of transactions. Based on these selectedconstraints, the tools may authorize every payment transaction thatmeets the aggregate constraints without requiring the buyer to authorizeevery transaction separately.

This Summary introduces, in a simplified form, a subset of the conceptsthat are further described below in the Detailed Description. ThisSummary is not intended to identify key or essential features of theclaimed subject matter, nor is it intended to be used as an aid indetermining the scope of the claimed subject matter. The term “tools,”for instance, may refer to system(s), method(s), computer-readableinstructions, and/or technique(s) as permitted by the context above andthroughout the document.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates an exemplary operating environment in which variousembodiments of the tools may operate.

FIG. 2 illustrates an exemplary flow diagram in which the tools enable ahuman buyer to select aggregate constraints for multiple paymenttransactions.

FIG. 3 illustrates an exemplary flow diagram in which the tools enable acomputing-entity buyer to select aggregate constraints for multiplepayment transactions.

FIG. 4 illustrates an exemplary flow diagram in which the toolsdetermine whether or not to authorize a payment transaction based on theaggregate constraints selected in FIG. 2 or FIG. 3.

FIG. 5 is an exemplary process illustrating some ways in which the toolsmay act to authorize or enable authorization of multiple paymenttransactions without requiring that a buyer or seller authorize eachtransaction separately.

The same numbers are used throughout the disclosure and figures toreference like components and features.

DETAILED DESCRIPTION Overview

An environment in which the tools may enable these and other actions isset forth below in a section entitled Exemplary Operating Environment.This section is followed by another section describing exemplary ways inwhich the tools may act to enable selection of aggregate constraints formultiple payment transactions and is entitled Aggregate Constraints. Thenext section is entitled Multiple Payment Transactions, and describesexemplary ways in which the tools enable authorization of multiplepayment transactions without a separate payment authorization for eachor an explicit authorization for any of the payments. A final sectiondescribes various other embodiments and manners in which the tools mayact, and is entitled Other Embodiments of the Tools. This overview,including these section titles and summaries, is provided for thereader's convenience and is not intended to limit the scope of theclaims or the entitled sections.

Exemplary Operating Environment

Before describing the tools in detail, the following discussion of anexemplary operating environment is provided to assist the reader inunderstanding some ways in which various inventive aspects of the toolsmay be employed. The environment described below constitutes but oneexample and is not intended to limit application of the tools to any oneparticular operating environment. Other environments may be used withoutdeparting from the spirit and scope of the claimed subject matter.

FIG. 1 illustrates one such operating environment generally at 100having four parties to a payment transaction: a buyer 102; a seller 104;a caller 106; and a payment authorizer 108. Each of these parties isshown with a computing device—three with servers and one with adesktop—though each may comprise one or multiple computing devices ofvarious types.

Each party may comprise one or more processor(s) 110 b, 110 s, 110 c,and 110 pa, respectively, which is capable of accessing and/or executingcomputer-readable media (CRM) 112 b, 112 s, 112 c, and 112 pa, alsorespectively. The buyer, seller, caller, and payment authorizer interactand manage their parts of a payment transaction with a buying module 114b, a selling module 114 s, a calling module 114 c, and an authorizingmodule 114 pa, respectively. Each communicates with at least one of theothers, such as through one or more communication networks 116 (e.g., acompany intranet and/or the Internet) or other communication path. Ifany of these parties share computing resources in a similar location,such communication may either be unnecessary or may be performed withouta communication network.

Buying module 114 b may include a network browser or other softwarecapable of interacting with the seller and/or caller, either with ahuman buyer or a computing-entity buyer (e.g., a program interactingwith the other parties through Application Program Interfaces (APIs)).The selling module similarly acts to provide online sales or servicesfrom a website intended for human use or through navigation to a programproviding services to a computing-entity buyer.

Each of the buyer, seller, and caller has associated paymentinstructions 118 b, 118 s, and 118 c, respectively. These paymentinstructions indicate what types or parameters of payments are approvedby each, ways in which payment transactions are desired to be handled,and other information. The payment instructions reference contextualdata (e.g., variables in payment transactions), parties to thetransaction, and the parties' accounts as well as other information.

The buyer's instructions, for example, may be defined or specified suchthat only payments of less than $100 are authorized. The seller'sinstructions, for example, may stipulate that only payments greater than$1.00 be authorized. The caller's instructions may require that paymentsbe made through particular banks or other financial entities. In somecases, payment instructions also include a party's preferences orinformation useful to other entities. A seller, for example, mayindicate that it is willing to pay all fees for a payment transactionbut preferably only if the buyer has not specifically agreed to do so.Or, also for example, a buyer's instructions may include informationabout the buyer that is useful to the seller but doesn't affect whetheror not the payment transaction will be authorized (e.g., the buyer'spurchasing trends or extra identifying information).

Any one of these sets of payment instructions may also include aggregateconstraints 120 b, 120 s, and 120 c, respectively. Aggregate constraintsare those that may apply to multiple payment transactions. An aggregateconstraint may limit a number of payment transactions or a definednumber of transactions in a predefined period of time, such as three inone day or five to one seller. An aggregate constraint may also limit adollar amount for a set of multiple payment transactions, such as a $100maximum to a same seller or $1,000 maximum for one year regardless ofthe number of sellers. Thus, for example, where the maximum is set to$100, if two payment transactions were previously approved, one for$13.56 and the other for $65.44 for a subtotal of $79.00, the third mayonly be authorized if it is $21.00 or less. Aggregate constraints aredescribed further in other sections.

In one implementation, the caller 106 includes the calling module 114 c,which is capable of requesting authorization of a payment transaction,also referred to as making a payment “call.” This request includes thepayment instructions for itself, the buyer, and the seller. The buyerand seller sets up or selects an account, payment instructions, and/oraggregate constraints through the calling module or authorizing module.

The payment authorizer's authorizing module 114 pa is capable ofreceiving a request for payment from the caller, determining if itshould be authorized based on the payment instructions, and thenauthorizing and/or executing the payment transaction. The authorizingmodule may build and retain a history of prior payment transactionsauthorized or not authorized. This history may be used to determine ifan aggregate constraint is met based on a currently requested paymenttransaction and prior, related payment transactions.

Aggregate Constraints

This section describes two examples where the tools enable selection ofaggregate constraints for multiple payment transactions. These examplesare implementations of the tools but are not intended to limit the scopeof the tools or the claimed embodiments.

These examples are illustrated in FIGS. 2 and 3, which show actions byand between calling module 114 c, authorizing module 114 pa, and twobuyers. The first example is illustrated in FIG. 2 at flow diagram 200,which shows a human buyer 102 h.

At arrow 2-1 in FIG. 2, calling module 114 c enables buyer 102 h toselect a set of one or more aggregate constraints for aggregate multiplepayment transactions. Here, the calling module includes or has access toa user interface 202 through which the user may select from theseaggregate constraints. For example, the user interface may providehuman-readable text indicating selectable aggregate constraints andreceive a selected set of aggregate constraints through selection of thehuman-readable text or graphical indicia associated with thehuman-readable text. The calling module may also enable selection of auser account and other payment instructions. The calling module mayenable these selections as part of a first purchase (e.g., the firsttime a buyer attempts to purchase a product or service from a website)or otherwise.

The calling module enables the buyer to select from the followingaggregate constraints: a maximum number of payment transactions; a totalmonetary cost; a time period for the maximum number; a time period forthe total monetary cost; a total maximum monetary cost regardless of anytime period; and a total maximum number of payment transactionsregardless of any time period. Assume that the buyer selects a maximumnumber of payment transactions at 5, the maximum monetary cost at $50,the time period for the maximum number of transactions at one week, thetime period for the maximum monetary cost at one month, and a totalmaximum monetary cost regardless of any time period of $500. Responsiveto this selection, the calling module builds, at arrow 2-2, the set ofconstraints 120 b. These constraints are included with paymentinstructions 118 b as shown in FIG. 2 at 120 b. For a maximum number ofpayment transactions of 5 with a time period of one week, the constraintmay be expressed as:

-   -   MyTokenUsageLimit1<=5;    -   MyTokenUsageLimit1Type=‘Count’;    -   MyTokenUsageLimit1Duration=1 week;    -   MyTokenUsageLimit1Start=‘2005-05-01 12:00 PST’;

For a maximum monetary cost of $50 with a time period of one month, theconstraint may be expressed as:

-   -   MyTokenUsageLimit2<=50;    -   MyTokenUsageLimit2Type=‘Amount’;    -   MyTokenUsageLimit2Duration=1 Month;    -   MyTokenUsageLimit2Start=‘2005-05-01 12:00 PST’;

For a total maximum monetary cost regardless of any time period of $500,the constraint may be expressed as:

-   -   MyTokenUsageLimit3<=500;    -   MyTokenUsageLimit3Type=‘Amount’;

Note that the calling module may enable the buyer to select all of theseconstraints at one time (i.e., as part of a discrete set ofinteractions). Also note that these constraints may be selected prior toa first requested payment transaction being requested or authorized,such as by enabling a buyer to go online, set up an account, decide onother, non-aggregate payment instructions, and decide on aggregateconstraints prior to requesting any payment transactions. A human buyermay do this through the buying module (e.g., a network browser) and userinterface 202 of the calling module 114 c.

The set of multiple payment transactions to which the aggregateconstraints applies may be governed by payment instructions as well asthe aggregate constraints themselves. For example, if a particular buyerattempts to purchase a product, the aggregate constraints may or may notapply to a payment transaction for that purchase. If the paymenttransaction is not within either of the two selected time periods, thenthe aggregate constraints may not apply. If they do not apply, thepayment transaction may not be authorized or may simply be handledwithout reference to the aggregate constraints (e.g., require a separateauthorization). Or the payment instructions may indicate that the set ofmultiple payment transactions is only for some sellers, or a particularseller, or for a particular bank, and so forth. Thus, in some cases theaggregate constraints may indicate that requested payment transactionsmust follow the aggregate constraints but only within a time period andonly for a particular seller.

In some other cases, however, aggregate constraints (e.g., an amount andnumber of payment transactions) are not bound to a particular timeperiod. In these cases the aggregate constraints may indicate thatrequested payment transactions must follow the aggregate constraintswithout regard to a particular time period.

The buyer “Billy” from the Background Section, for example, may beenabled by the calling module to select a set of five online-gamingsellers and a time-period of one month. He may also select that thetotal monetary cost for payment transactions requested through thosesellers and during a defined period be $100. But he may forgo setting amaximum number of transactions during that period. In so doing, he maychoose to play a game online for $0.30, a hundred separate times withinthat month, and some other games from other sellers, so long as thetotal of the payment transactions add up to $100 or less within theone-month time-period. Here, he may play over a hundred separate gamesin a month without separately authorizing any of them. Billy simplybegins playing the games whenever and however he likes so long as thecumulative cost of the games does not exceed his $100 limit per month.

At arrow 2-3 in FIG. 2, the calling module passes payment instructions118 b and aggregate constraints 120 b to authorizing module 114 pa. Theauthorizing module receives the payment instructions and aggregateconstraints. The authorizing module then builds a unique identifier 204for those aggregate constraints, shown at arrow 2-4. This uniqueidentifier, also called a “token”, may indicate aggregate constraints byincluding the aggregate constraints within the unique identifier. It mayalso or instead indicate a location to find the constraints or a mannerin which to determine those constraints, such as in history 122 of FIG.1.

In this embodiment the unique identifier is usable to determine thepayment instructions and aggregate constraints, is cryptographicallyunique (e.g., encoded), and is a long string of alphanumeric characters.The authorizing module retains a copy of this unique identifier 204 andassociates it with the payment instructions (including the aggregateconstraints). It then passes the unique identifier to the calling moduleat arrow 2-5. The calling module then passes the unique identifier tothe buyer module at arrow 2-6. The buying module may later use thisunique identifier to purchase items without requiring the buyer toseparately authorize payment transactions for each purchase.

Another example is illustrated in FIG. 3 at flow diagram 300, whichshows a computing-entity buyer 102 ce. In this embodiment, the toolsenable computing-entity buyer 102 ce to select aggregate constraints formultiple payment transactions. This example shows the entities andactions of the above example except as noted below.

Computing-entity buyer 102 ce may include or interact with buying module114 b of FIG. 1 to select aggregate constraints. The buying module heredoes not include a network browser but instead contains applicationprogram interfaces (API) through which the buying module may enable thecomputing-entity buyer to select aggregate constraints made availablethrough program interface 304. Thus, at arrow 3-1 the buying module usesAPIs effective to cause the program interface to receive selectedaggregate constraints. The other actions and interactions at arrows 3-2to 3-6 may act is substantially the same manner as their counterparts inFIG. 2 but in the context of a computing-entity buyer.

This and other computing-entity buyers and sellers may desire topurchase or sell items without separately authorizing paymenttransactions for each. Examples of these include websites that desire topurchase items and services from other computing entities. A searchwebsite, for example, may wish to use a mapping service of anothercomputing entity (e.g., a computing-entity seller) and pay for each useso long as such use is within certain aggregate constraints. Every timea user of the buyer's search website uses the mapping service throughthe buyer's website, the buyer may authorize a payment transaction forone cent, for example. If the buyer or seller selects aggregateconstraints permitting a maximum number of payment transactions in aperiod, e.g., 100,000 per day, with a minimum and maximum cost of onecent, the buyer and/or seller may purchase or sell this mapping servicewithout a separate authorization for each (or any authorization outsideof selecting constraints and payment instructions).

In any case, whether the entity selecting aggregate constraints is abuyer or seller or human or computing entity, the tools permit selectionof aggregate constraints. With these aggregate constraints—hereindicated with unique identifier 204—the tools permit buyers and sellers(or even callers) to authorize payment transactions for items andservices without separate authorizations for each. These examplescontinue in the following section in which the unique identifier is usedby the authorization module to determine whether or not to authorizepayment transactions.

Multiple Payment Transactions

This section continues the above examples in part and describes ways inwhich the tools determine whether or not to authorize paymenttransactions based on the aggregate constraints selected above andindicated in the unique identifier 204 of FIGS. 2 and 3. These examplesare implementations of the tools but are not intended to limit the scopeof the tools or the claimed embodiments.

At arrow 4-1 illustrated in FIG. 4 at 400, buyer 102 (e.g., 102 ce or102 h) through buying module 114 b interacts with selling module 114 sto purchase an item or service. As part of this interaction the buyingmodule may send, and the selling module may receive, the uniqueidentifier 204 built in FIG. 2 or 3. Note that the buyer (whether humanor not) may not have made any explicit authorization for a paymenttransaction. Instead, a human buyer desiring to play video games mayjust select to play the game. Or, also instead, a human buyer may simplyselect an item (e.g., a CD in the above example) with nothing more.Following this selection and without requiring an explicit authorization(or, in some cases, an additional interaction of any kind) from thebuyer, a payment request is made. After the request is made, a paymenttransaction may be authorized, also without further interaction from thebuyer. In the case of the above computing-entity buyer, the buyer mayenable users to use the seller's mapping service automatically andwithout any explicit authorization by the buyer or its users.

At arrow 4-2 the selling module transmits the buyer's unique identifierand the seller's payment instructions 118 s (including aggregateconstraints 120 s, if any), to the caller 106. The seller's paymentinstructions may be sent in total or the selling module may send aseller's unique identifier built similarly to that of the buyer's uniqueidentifier (not shown). This seller's unique identifier is usable todetermine the seller's payment instructions and aggregate constraints ata future part of the process.

The caller receives the buyer's unique identifier 204 and the seller'spayment instructions 118 s at arrow 4-2. In response, the caller'scalling module combines the buyer's unique identifier, the seller'spayment instructions, and the caller's payment instructions into apayment request, shown at arrow 4-3. This request is shown at 402 andincludes this information as well as information specific to thepurchase 404. This information here includes the buyer's identity(though this is also determinable with the buyer's unique identifier),the seller's identity (also determinable), the caller's identity (alsodeterminable), the date of the attempted purchase (e.g., Dec. 13, 2005),and the cost (e.g., an online game to be played for $1.12).

Continuing one of the above examples, the payment request may includethe following: 1) the caller's payment instructions 118 c indicating thecaller's identity and that the caller is not paying any fees for thispayment transaction; 2) the seller's payment instructions 118 sindicating the seller's identity, that the payment transaction can onlybe for receiving money (i.e., the seller is not sending money), thatpayments may be received only from credit cards and bank accounts, thatthe amount of payment must be at least $0.10, and that the seller agreesto pay the fee for this payment transaction; 3) the buyer's uniqueidentifier 204, which is associated with the buyer's paymentinstructions and aggregate constraints; and 4) information 404 includingthe price of $1.12 and the date of Dec. 13, 2005.

The buyer's payment instructions indicate which sellers may receivepayments (e.g., one of five online game sellers), that money may only besent (not received), and the credit card number in the buyer's account.The buyer's aggregate constraints indicate that the maximum monetarycost is $100 in a period of one month beginning Dec. 1, 2005 and thatthere are no maximum number of payment transaction or any period for anumber of payments.

At arrow 4-3 the authorizing module 114 pa receives the payment requestfrom the caller. At arrows 4-4 the authorizing module determines whatare the payment instructions 118 b and aggregate constraints 120 b basedon the unique identifier 204. The authorizing module retained thebuyer's payment instructions including aggregate constraints in thehistory 122 as part of the actions illustrated in FIG. 2 or 3. With theprior association between the unique identifier and the paymentinstructions and aggregate constraints, the authorizing module decodesthe unique identifier and determines the appropriate instructions andconstraints. As noted above, these include the maximum monetary cost andthe purchase date. The result of arrows 4-4 is a decoded payment request406 including all payment instructions (and aggregate constraints) forthe buyer, seller, and caller, and information 404.

At arrow 4-5 the authorizing module determines whether or not theaggregate constraints of the payment request are met. Here the buyer hasaggregate constraints of $100 within a period of one month beginningDec. 1, 2005. Thus, the authorizing module determines whether thisparticular payment request, when aggregated with all prior authorizedpayment requests within this period or associated with this uniqueidentifier, are or are not met. To do so, the authorizing module refersto the history 122. The history 122 shows that this unique identifierhas been used twice before and that two payments were authorized. Thesetwo were also for online games within the Dec. 1, 2005 to Dec. 31, 2005time-period. The first was on Dec. 2, 2005 for $3.43 and the second wason Dec. 4, 2005 for $1.11. As the total for these two prior authorizedpayments is $4.54 and, combined with the requested payment of $1.12 isonly $5.66, the aggregate cost for this and prior payments is well underthe maximum of $100. Thus, the authorizing module determines that theaggregate constraints are met and the transaction proceeds.

Also as part of arrow 4-5, the authorizing module determines if theother, non-aggregate payment instructions are also met. For example, theauthorizing module may determine if the seller is one of the fiveauthorized sellers. If the authorizing module determines that all of thepayment instructions for all three entities are met, the authorizingmodule authorizes or enables execution of the payment transaction atarrow 4-6. This authorization may indicate to some other entity toactually make the payment, here payer 408.

At arrow 4-7, the authorizing module records the authorization, paymentinstructions, and information in the history 122. The history nowincludes three payments authorized for the buyer's unique identifier.The authorizing module may use this history for the next requestedpayment having this unique identifier.

Note that the buyer, here Billy—who wanted to play an online videogame—was able to do so without an express or explicit authorization.Note also that Billy didn't separately authorize this payment or theother two recorded in the history.

Other Embodiments of the Tools

The above sections describe particular examples where specific entitiesof the exemplary embodiment, such as the buying, selling, calling, andauthorizing modules act and interact to authorize payment transactions.In this section, other embodiments of the tools are described in whichthe tools are capable of authorizing or enabling authorization ofmultiple payment transactions without requiring that a buyer or sellerauthorize each transaction separately.

These other exemplary embodiments are described as part of process 500of FIG. 5. This process and the flow diagrams described and illustratedin FIGS. 2 through 4 may be implemented in any suitable hardware,software, firmware, or combination thereof; in the case of software andfirmware, this process and any of these flow diagrams represent sets ofoperations implemented as computer-executable instructions stored incomputer-readable media and executable by one or more processors.

Block 502 of FIG. 5 enables a user to select a set of one or moreaggregate constraints for aggregate multiple payment transactions. Theseaggregate constraints may include many factors or conditions that abuyer, seller, or caller may want to select for a set of aggregatepayment transactions, such as a maximum total monetary cost of themultiple transactions, a maximum total number of multiple transactions,and time periods for each or both. Some of the above examples, forinstance, provide for an aggregate price and an aggregate number oftransactions.

Block 502 may enable a user to select these aggregate constraints priorto or incident with an attempt to purchase. Thus, a buyer may selectconstraints when he or she attempts to purchase a first of many items orservices. Likewise, a seller or caller may do the same. Users may alsoselect constraints prior to any purchases, such as a buyer setting up anaccount on the seller's website either with or without help from thecaller.

Block 502 may also enable a user to select aggregate constraints formany transactions at one time. As described in the above examples, thisenables a user (be it buyer, seller, or caller), to implicitly authorizemany transactions without explicitly or separately authorizing any ofthem.

Block 502 may enable these actions for people or remote softwareapplications, such as with a user interface for a human buyer or APIsfor computing-entity buyers or sellers. Examples of these are set forthabove.

Responsive to the act of enabling the user to select constraints, block504 receives a selected set of one or more aggregate constraints. Asnoted in the examples above, this may be through a user interface or aprogram interface using APIs or other known manner. The calling module114 c of FIGS. 1-4 may enable, in some embodiments, both of blocks 502and 504, either with direct communication with a user or through anotherentity. In the above examples the calling module interacts directly witha buyer, though it may also work in conjunction with a seller tointeract with the buyer (e.g., by enabling a buyer to set up an accountand select constraints through the seller's website).

Block 506 builds a unique identifier associated with the selectedaggregate constraints. As noted above, this unique identifier mayinclude or be usable to determine the selected aggregate constraints. Inthe above examples the unique identifier is an encoded alphanumericstring built and usable by the authorizing module to find the associatedaggregate constraints. The unique identifier may be retained by the userfor multiple uses, such as if the buyer retains its unique identifierand passes it to many different sellers for many different requests topurchase items or services.

Block 508 receives a request to execute a payment transactionconstrained by the selected set of aggregate constraints. In some casesthe tools determine if a particular requested payment transaction isassociated with the selected set of aggregate constraints. The tools maydo so based on an association between the payment transaction and theunique identifier, such by the payment transaction including the uniqueidentifier as part of a payment call.

Block 510 determines whether the selected set of aggregate constraintsare satisfied based on information associated with the paymenttransaction and, in many cases, a history of one or more prior paymenttransactions of the aggregate multiple payment transactions. Thisinformation may include a price, time, and identify of the parties tothe transaction. The history may indicate time periods in whichaggregate constraints apply, an aggregate price of payments previouslyauthorized for payment, and a number of transactions previouslyauthorized.

For example, if the information indicates that the price for therequested payment transaction is above a maximum monetary cost whenaggregated (e.g., summed) with the aggregate monetary cost of previouslyauthorized payment transactions that are associated with the same set ofaggregate constraints, the tools will not authorize the payment.Similarly, if the history indicates that 100 payment transactions havepreviously been authorized or executed and which are associated withthese aggregate constraints, the tools will not authorize a requested101^(st) payment transaction if the maximum total number of paymenttransactions is 100. This assumes that there is no time period set orthat they are all within a set time period.

If block 510 determines that the aggregate constraints are satisfied,the tools may proceed to block 512 or 514 along either “Yes” path. Ifthey are not satisfied, block 510 proceeds along the “No” path to block516.

The tools may—but are not required—to authorize execution of or executethe requested payment transaction if the aggregate constraints are met.If the tools proceed to block 512, they first determine whether other,non-aggregate payment instructions are met. Block 512 may do so byreceiving an indication that other non-aggregate payment instructions(e.g., payment instructions 118 excluding aggregate constraints 120) areor are not satisfied. Block 512 may also do so by itself analyzing thenon-aggregate payment instructions to determine if they are met.

Assume, for example, that block 510 determined that the requestedpayment transaction meets the selected aggregate constraints. Assumealso that block 512 determines that the selected payment transaction isfor $0.70 and that the non-aggregate payment instructions indicate thatthe minimum payment transaction is $1.00. In this case block 512 willnot authorize the payment transaction even though the aggregateconstraints are met. Other examples of how the tools may determine toauthorize requested payment transactions are set forth above.

If block 512 determines that the non-aggregate payment instructions arealso satisfied, it proceeds along a “Yes” path to block 514. Otherwiseit proceeds along a “No” path to block 516. Block 516 refrains fromauthorizing or executing the requested payment transaction.

Block 514 authorizes or executes the requested payment transaction inresponse to block 510 or 512. Once authorized, the tools proceed toblock 518. Block 518 records information about the authorized paymenttransaction, such as its price, time period, and identity of the partiesto the transaction. This record (e.g., history 122 of FIG. 1) is usablefor successive iterations of process 500 or its parts (e.g., blocks508-514) by which the tools may determine if aggregate constraints offuture requested payment transactions are met.

By way of review, consider the online-gaming example given above in thecontext of process 500. In this example the history 122 showed that aunique identifier had been used twice before and that two payments wereauthorized. These two were for online games within the Dec. 1, 2005 toDec. 31, 2005 time-period. The first was on Dec. 2, 2005 for $3.43 andthe second was on Dec. 4, 2005 for $1.11. The total for these two priorauthorized payments is $4.54. Assume that the tools authorized arequested payment transaction for $1.12 because when summed with theprior-authorized payment transactions the sum is only $5.66, which iswell under the maximum of $100. The tools, having now authorized apayment transaction for $1.12, record information associated with thispayment transaction into history 122. Thus, the history may now indicatethat three transactions have been authorized for three different sellersand that the total amount authorized is $5.66. If another request isreceived at block 508 that also is associated with the same set ofaggregate constraints, it may be authorized if the requested amount isless or equal to $94.34 ($100.00−5.66=$94.34).

CONCLUSION

The above-described tools are capable of authorizing or enablingauthorization of multiple payment transactions without requiring that abuyer or seller authorize each transaction separately. By so doing, thetools enable parties to payment transactions to forgo authorizing eachpayment transaction. A buyer, for example, may forgo tens, hundreds, oreven millions of separate payment authorizations by selecting aggregateconstraints for those payment transactions. Although the tools have beendescribed in language specific to structural features and/ormethodological acts, it is to be understood that the tools defined inthe appended claims are not necessarily limited to the specific featuresor acts described. Rather, the specific features and acts are disclosedas exemplary forms of implementing the tools.

1. A method implemented at least in part by a computing devicecomprising: enabling a user to select an aggregate price or aggregatequantity of transactions for a set of multiple payment transactions;receiving, from the user and responsive to the act of enabling, aselected aggregate price or aggregate quantity; and providing a uniqueidentifier associated with the selected aggregate price or aggregatequantity effective to: enable a payment transaction requested by orassociated with the user to be associated with the selected aggregateprice or aggregate quantity; and enable a determination of whether therequested payment transaction satisfies the selected aggregate price oraggregate quantity when aggregated with a previously authorized orexecuted payment transaction of the set of multiple paymenttransactions.
 2. The method of claim 1, wherein the act of enabling theuser further enables the user to select a time period for the selectedaggregate price or aggregate quantity.
 3. The method of claim 2, whereinthe act of providing enables a determination of whether the requestedpayment transaction satisfies the selected aggregate price or aggregatequantity when aggregated with the previously authorized or executedpayment transaction and where the previously authorized or executedpayment transaction was requested within the time period.
 4. The methodof claim 1, wherein the act of enabling the user provides a userinterface with human-readable text indicating selectable aggregateconstraints and the act of receiving receives the aggregate price oraggregate quantity through selection of the human-readable text orgraphical indicia associated with the human-readable text.
 5. The methodof claim 1, wherein the act of enabling the user provides an applicationprogram interface (API) through which a remote software application mayinteract sufficient to select the aggregate price or aggregate quantityand the act of receiving receives the aggregate price or aggregatequantity through the API.
 6. The method of claim 1, wherein the act ofproviding enables a determination of whether the requested paymenttransaction satisfies the selected aggregate price or aggregate quantitywithout explicit authorization from the user.
 7. The method of claim 1,wherein the act of enabling the user enables the user to select all ofthe constraints at one time.
 8. The method of claim 1, wherein theunique identifier is a token having a character string.
 9. The method ofclaim 1, wherein the act of receiving the selected aggregate price oraggregate quantity receives the selected aggregate price or aggregatequantity prior to authorization of or execution of the previouslyauthorized or executed payment transaction.
 10. The method of claim 1,wherein the selected aggregate price or aggregate quantity comprisesboth a selected aggregate price and a selected aggregate quantity. 11.The method of claim 1, wherein the selected aggregate price or aggregatequantity comprises only one of a selected aggregate price and a selectedaggregate quantity.
 12. A method implemented at least in part by acomputing device comprising: enabling a user to select a set of one ormore aggregate constraints for aggregate multiple payment transactions;and receiving, from the user and responsive to the act of enabling, aselected set of one or more aggregate constraints constraining theaggregate multiple payment transactions, the selected set of aggregateconstraints effective to enable a determination of whether or not arequested payment transaction meets the selected set of aggregateconstraints when the requested payment transaction is aggregated withpreviously requested payment transactions that met the selected set ofaggregate constraints.
 13. The method of claim 12, wherein the act ofenabling the user to select the set of one or more aggregate constraintsenables the user to select the constraints at one time.
 14. The methodof claim 12, wherein the act of receiving the selected set of one ormore aggregate constraints receives the set of one or more aggregateconstraints prior to authorization of or execution of any of thepreviously requested payment transactions.
 15. The method of claim 12,wherein the act of enabling the user provides an application programinterface (API) through which a remote software application may interactsufficient to select the selected set of aggregate constraints and theact of receiving receives the selected set of aggregate constraintsthrough the API.
 16. The method of claim 12, wherein the act of enablingthe user provides a user interface with human-readable text indicatingselectable aggregate constraints and the act of receiving receives theselected set of aggregate constraints through selection of thehuman-readable text or graphical indicia associated with thehuman-readable text.
 17. The method of claim 12, further comprisingreceiving a request to authorize or execute the requested paymenttransaction.
 18. The method of claim 17, further comprising determiningthat the requested payment transaction meets the selected set ofaggregate constraints when the requested payment transaction isaggregated with the previously requested payment transactions that metthe selected set of aggregate constraints.
 19. The method of claim 12,wherein one of the selected set of aggregate constraints sets a maximumtotal monetary cost for the aggregate multiple payment transactions. 20.The method of claim 12, wherein the one of the selected set of aggregateconstraints setting the maximum total monetary cost for the aggregatemultiple transactions comprises a time period in which the maximum totalmonetary cost is based and outside of which transactions are notconsidered part of the aggregate multiple payment transactions.